Talk:FloatingToc
Get rid of the fancy stylings I really like this script, and I saw the use for it, but there are a few potential problems: *the styling effects that you applied is not exactly to my taste *the button to make it float from the article overlap the mediawiki's show link I suggest the following: *Make the stylings as simplistic as possible. I'd prefer the "Contents" part, the part where you can grab and drag the toc, to be the same colour as the wiki-navigation, made the whole toc resizeable, and that's it. *Replace the 'float' button from looking like a button to a link, like mw's show link, in order to make the look more uniform. Or you can do it the other way round. *Don't fix the 'float' button's position as it occupies the same space as the show button. I really like this one and I hope you'll look into it. —[[User:Mfaizsyahmi|''mfaizsyahmi]] (talk) 04:33, November 5, 2012 (UTC) :That touches upon questions of taste. There's no deciding those, you know? All I can say is: I like the design the way it is. Now if you're telling that something is broken: That's another story. I did notice myself that the positioning of the "open dialog" button doesn't work on some pages - simply because the table of contents is too narrow. That's annoying. Adding a text-link won't help much. The text-link is bound to be larger than the button. :I'll have to try a few things... -- pecoes 06:18, November 05, 2012 (UTC) Few bugs/quirks Just been playing with it on a few articles. I love it so far, but a few things I've noticed: *After resizing the window, the code doesn't allow you to move the ToC into the new screen area. *When scrolling the ToC list, it is very easy to accidentally scroll up/down the page when you hit the ends of the list. :You're a day too late :) I rewrote the code from scratch today. Can I contact you for beta-testing when I'm done? -- ::Sure. Didn't realise you were already fixing it. ;) :::Alright. Here's the Beta version: '''FloatingToc/beta.js'. Let me know if you find any bugs, please! -- :A couple of things: :*The floating box has horizontal resize cursors when hovering over the left/right edges. :*Scrolling is still annoying to do within the ToC - not sure if you can actually fix this or not... :*Line spacing could be increased in my opinion to match the actual ToC. : ::*The panel should be resizable. I'll have to check why it isn't... ::*I'll try to fix the scrolling. ::*The smaller line-height is intentional. FloatingToc is meant for pages with very long tables of content. The less you have to scroll inside the TOC the better. ::I'll collect a few more bug reports and feature suggestions before working on it again, if it's all the same to you. -- Testing new! Hi, when I click test new beta button on the page it takes me to one of the headlines is this supposed to happen? OriginalAuthority 22:31, December 2, 2012 (UTC) :It's supposed to reload the page and the Demo code with it. -- Demo How is the demo supposed to work exactly? I see the icon appear in the table of contents just when normally loading the page, so it seems like the demo automatically runs on this page. I'm not sure what the blue buttons are for in the Demo section or why you need them then. :Clicking on one of the buttons will set a flag in sessionStorage, reload the page and - depending on the flag - load one of the two demos. If you see the icon in the TOC before you've clicked on one of the buttons, you already have FloatingToc installed. In that case edit your global.js instead, please. :That two-button solution is only temporary btw. I want to get the beta out of beta ASAP. Beta.js I've been testing FloatingToc/beta.js by copy/pasting into the console. Here's a couple bugs I noticed (all in Firefox + Oasis): *When floating, the TOC is empty for logged out users. *The movement is not constrained by the window. It should be. If you move the top part of the TOC off the top of your screen, it's impossible to recover it as the only draggable portion is off the edge of the screen and position is fixed. *When floating, the TOC goes under the Wikia header and the toolbar. It needs to have a z-index of at least 20000002 to make sure that it stays on top. :*fixed :*I had that constraint for the longest time, but I couldn't make it feel right. It felt intrusive. That's why I removed it. Well. That and the fact that the jQuery UI widgets are a bit finicky. If you don't use them in exactly the way they were designed, you're asking for glitches, blockages and whatnot... Quite frankly: Writing this addon was pain in the arse. Absolutely everything I did had unintended and inscrutable side effects. You know I'm not the kind of person who minds a few hours of blind guessing, but this tested even my patience :( :*fixed : ::I know how to fix the draggable issue (having used both draggable and resizable in the CSS Pad project), but there is an HTML base problem resulting from your resizable code that prevents me from doing so. If you're okay with me rewriting the resizable part, I could take a crack at fixing it? :::If you want to knock yourself out, use the constraint object instead of the window object. The constraint never overlaps the Wikia-footer or -header. Set the constraints background-color and opacity to see it on the page. The constant MARGIN specifies the margin the constraint will add to the legal area. -- Fixed, and without touching your resizable code like I originally thought I would have to. The main issue is that you're using the dialog() method -- which sneakily creates the outermost container: *I had to dynamically add id="tocDialogWrapper" to the container (so that I can apply CSS to the container) *The container needs to be permanently set to position: fixed. It's not safe to be inline because the style attribute gets modified (and position: fixed is removed) by draggable. *The container needed to be permanently set to a z-index high enough to keep it on top of everything else **Some stupid part of either the draggable or resizable script adds z-index values to the style attribute, so I had to use !important to override the inline z-index. *draggable() needed to be told what the containment is. If you use resizable again, my advice is to use the resizable() method, not... whatever else you're doing that doesn't make sense to me :P P.S. I tried to use your "constraint" box, but it doesn't move when you scroll up and down the page. Also, yes it does indeed overlap with the Wikia footer and header, contrary to your claim. :Reading that made me angry. Why does he tell me all these things I already know? And why does he fix issues that I already fixed? Wtf? Just from reading your post I was about to revert your edit without even looking at it. :Fortunately I did. Solving the z-index issue and the position issue with CSS only is indeed better than solving it with JavaScript. Inline declarations override rules. That's why it hadn't occurred to me to set the z-index with CSS. And the !important keyword is something I normally avoid like the plague. But I guess this where I should make an exception. :But know this: I've tried about a million things and as I said: Everything seemed to have had unintended and intractable side effects. Just because you accidentally stumbled on a solution that doesn't, does not mean you understand anything better than I do. Heck, you dont' even understand most of my code! It just means you were lucky. :So: Thanks for the fix, but no thanks for the lecture! But again: Thanks for the fix! -- ::Wait. No. The only reason why your CSS solution for the position seemed to work, is because you left my JavaScript code that overrides the position in there. I just took it out - hoping it would no longer be needed and suddenly I got negative values for top. Your "fix" for the position didn't work. It was simply ignored. The z-index might work, but I'll have to test that carefully... -- :::You're welcome to revert the edit if it's not helpful. Like I said, I do not understand your code base well as well as you do, so maybe my change doesn't fit well with the rest of it. In any case, I was just trying to explain what I did and why, as there was a thought process behind it and it was backed up by some testing, the feature was functioning properly after my change, it's not like I did something random for no reason. I'm sorry if the way I worded things was not appreciated. That being said, whatever you do, please make the reasonable design decision of requiring the container to at least stay inside the window when it's dragged, please and thank you. ::::It seems I just disregarded the first rule of wiki-editing: Never react emotionally to an edit! Sorry about that. That was rude of me. I was more angry at the jQuery UI than at you anyway. Of course you only meant well and I appreciate that you explained the reasoning behind your changes. But while I'm sure you tested the code, you don't seem to have tested it with very long TOCs and/or resized the window to make it too small for the TOC's current height. Because those are the issues that need to be solved before adding the draggable constraint. But you've convinced me to add it (back) in! That's a good idea. -- Worry not.. ..I want to bring something really minor to your attention; no complicated bugs (yet, since I just started using it). Just a minor thing. Capitalise at least the first word in the buttons' hover bubbles, and also add an appropriate hover bubble for the float/open/whatever-you-call-it button. Cheers mate. --[[User:Noemon|''Noemon]][[User talk:Noemon| *'talk'*'']] 08:11, December 6, 2012 (UTC) :I'm not worried. I like bug reports. They help me make my code better :) :I fixed the captions, but you'll have to wait a few hours. There are a few slightly more complicated things I'll have to fix as well before I upload the next version. The button in the TOC that opens the floating panel does have a caption however. It used to say "open". It says "Open" now :) Does your browser not display this caption? Or did you mean a different button? -- ::That's the button I meant, it's just that I am not using the beta (and the moment I left my first post I had not checked the code of the beta). ::By the way, now that I am on Chrome, I noticed that when the ToC is in its floating state, and I scroll, it gets left behind, for a fraction of time, while its absolute positioning is recalculated (still not talking about the beta version). I did not notice this behavior while I was on Firefox. What if you used fixed positioning instead? Cheers --[[User:Noemon|''Noemon]][[User talk:Noemon| *'talk'*'']] 09:51, December 6, 2012 (UTC) :::I do use fixed position now. That animation is just to distracting. -- No more beta The next version is out of beta as of now. -- :I think there is something wrong with your last edit. When pressing the Open button (which also started looking wrong by the way) the ToC disappears. Plus the anchor links next to the headings disappeared. --[[User:Noemon|''Noemon]][[User talk:Noemon| *'talk'*'']] 11:36, December 7, 2012 (UTC) ::Should be fixed now. Try again (in ten minutes), please! -- :::Fixed indeed. --[[User:Noemon|''Noemon]][[User talk:Noemon| *'talk'*'']] 13:49, December 7, 2012 (UTC) Hungarian localization hu: { contents: 'Tartalom', toc: 'Tartalomjegyzék', open: 'Kinyit', close: 'Összecsuk', back: 'Vissza a tetejére', reset: 'Alaphelyzetbe állítás' }, TK-999 (talk) 18:50, January 3, 2013 (UTC) : Köszönöm! :) -- jquery.ui I assume there's a reason you're importing the ui, but you can just add a dependency for it - it's one of the default ResourceLoader modules. It can't be faster to import the entire thing again. :Good point! That's definitely outdated! :) -- :Actually, no, forget what I just said. I only import the jQuery UI CSS. That could probably be streamlined since not all of it is necessary, but that's a minor point. The JS libraries are imported with mw.loader.using at the very bottom of the code. And only the relevant ones are imported - namely jquery.ui.dialog and jquery.effects.slide. :It's been a while so I forgot what I did there. Sorry for the conflicting replies! -- Empty TOC while floating Hi, TOC is empty, when it is switched to floating. -- 22:22, October 29, 2013 (UTC) I am having this problem on my Wiki as well. Please fix this soon. William, Bureaucrat/Administrator of the Lord of Ultima Wiki (Talk) 05:31, November 19, 2013 (UTC) The fix I applied appears to correct this issue, at least on my end it does... Can anyone else confirm whether or not it's working (using the demo on FloatingToc)? —RyaNayR (talk) 21:45, November 23, 2013 (UTC) :Update: Apparently the fix only works when using Firefox. :Description of the problem: It has something to do with how the script retrieves the list of contents from the original ToC, which it tries to insert into the new floating ToC window. But it fails to do so. The issue seems to originate from this line: list = root.find('ul:first'), :When I changed it to ('ol:first') it became functional in Firefox, but still broken in any other browsers. :—RyaNayR (talk) 00:56, November 24, 2013 (UTC) ::Your fix appears to be working for me in Chrome and IE10. Perhaps what you're seeing is a little time for the cache to update? ::A word of warning though - it's a good idea to test any changes to scripts before submitting them to the live version to avoid any unforeseen bugs, especially with a script that could affect many wikis and users. :::Well, before the fix it would say "undefined" in the TOC window. Afterwards, in Chrome (latest ver.) and IE9 it is just blank. It also appeared the same way for another user, on both Chrome and IE. :::And yeah, I had considered that, but it appeared to have broken for most if not all users (probably due to a Wikia update), and I tested it on another wiki before making any changes here. But still. I probably should have done more testing, or submitted a beta instead. I will do so in the future. Thanks for the advice. —RyaNayR (talk) 01:26, November 24, 2013 (UTC) Czech translation cs: { contents: 'Obsah', toc: 'Obsah', open: 'Otevřít', close: 'Zavřít', back: 'Nahoru', reset: 'Reset' }, --Darth Daron (talk) 17:58, September 18, 2014 (UTC) Requests Can you make the contents respect headings and make the default floating position over the rail where the wiki activity is? Alysdexia (talk) 08:24, November 7, 2014 (UTC) Width Bug On the Dresden Files Wiki, & other Wikis I have this installed, there is a recurring bug that shrinks the TOC widths down to a sliver, instead of being fluid with the contents of the TOC. A fix I’ve used on my home wiki involves manually setting widths for each individual page, to ensure that they are forced to hold a specific width, & that solves the issue. However, it does not account for page changes, & the static width can prove troublesome when headers are changed. It also takes a long time to set this fix up, since a rule has to be made for every single page on a wiki. On bigger wikis it would be impossible. Is there a way to fix this so that the bug no longer occurs? That would be a much more effective & elegant solution than what I’ve been trying. :I can confirm I'm having the same problem on all wikis I have checked, so I would like to ask for a fix too. -- 22:25, March 19, 2017 (UTC) ::To piggyback on this, I'm having trouble getting the text to even appear in the TOC. I've tried FireFox and Chrome, on different wikis too, and still, the problem persists. --Regular Guy 18:10, March 23, 2017 (UTC) Numbering Hey Pecoes, could your script respect numbering and indents? Best regards, Agent Zuri Profile Message Wall Blog 16:12, February 12, 2019 (UTC) :I'm not Pecoes, but I had a look and am pretty sure this is a bug from when Fandom changed the ToCs to be lazy-loaded. I've so numbering/indents are shown again. - OneTwoThreeFall talk 11:07, February 13, 2019 (UTC) ::Hey OneTwoThreeFall, thanks for the changes. Looking forward to see them when they are reviewed! ::Agent Zuri Profile Message Wall Blog 14:27, February 13, 2019 (UTC) Issue - popup triggering in the VisualEditor It looks like the current version can be activated while in the VisualEditor - typing a 't' in the editor causes the popup to appear. I believe it needs to be disabled while the VisualEditor is open. -- Kirkburn (talk) 19:45, June 13, 2019 (UTC) :Fix applied, thanks. -- [[User:KhangND|'Khang']] (talk) 00:18, June 14, 2019 (UTC) ::No, thank you! :) -- Kirkburn (talk) 15:22, June 14, 2019 (UTC) The icon is invisible In this image you can see calmly that the icon that activates FloatingToc is gone. Can you fix that? AndreMor 17:06, July 20, 2019 (UTC) : What wiki is that on? -- Cube-shaped 17:07, July 20, 2019 (UTC) :: Wubbzypedia -- AndreMor 00:43, July 21, 2019 (UTC) :::This probably has something to do with the technical update. I see some changes in CSS files. Will try to fix it ASAP. -- [[User:KhangND|'Khang']] (talk) 07:49, July 21, 2019 (UTC) ::::Still invisible. :::::This is a result of FandomizedButtons overriding the background-image for FloatingToc's button with an !important (per line 20 of the stylesheet). I've sloppily exempted this button from being affected by the rules that mess with with background-image in . puxlit (talk) 05:49, December 25, 2019 (UTC); edited 06:08, December 25, 2019 (UTC)